\section{Differences in the Second Version of the Document}
\label{sec:diff}

This section describes the changes applied in this version of the document, compared with the previous version. The changes are motivated by issues we encountered during the implementation process, and applied to achieve a more complete or sound definition of the protocol, and a simpler implementation.

\subsection{PDU Definitions}
In the second version of the protocol we applied several important changes to the PDUs:
\begin{enumerate}
\item {\em All} messages begin with a unique byte that indicates the message type, for instance 0 for a poke message, 1 for a version message, 2 for error etc. In the previous version, most messages had a type, except the version message and the client challenge response message. In the previous version, the choice was motivated by what is used by a real-world protocol (RFB), however we added a type for {\em all} messages in order to:
    \begin{enumerate}
        \item Have a consistent message format
        \item Be able to easily assert whether any given message at any given state is legal at that state or not
    \end{enumerate}
\item In the previous version, after the connection is initialized and the client can send actions to the server and receive confirmations, we allowed the client to send more actions, as it awaits confirmation for older actions he sent. This defined an asynchronous behavior, which we wanted to eliminate.
    Therefore, now the client is allowed to send only {\em one} action and must wait for the server to confirm / deny that action. It follows that the server can have at most {\em one} pending action to confirm / deny for any active client at any given time.
\item As detailed in \sect{sec:pdus:pdu:impl}, our implementation disguises the byte-stream messages defined in the PDU section as newline-delimited strings. The PDU section still addresses messages as streams of bytes, and only the implementation uses this shortcut to simplify the code (we simply use Java buffered readers to read complete messages instead of reading byte after byte). The spec in this document is kept as in the original, addressing messages as streams of bytes, since it is the more efficient way, and anyone who wishes to supply a real efficient implementation of our protocol should not take the shortcut we did and follow the spec.
\item In the original {\tt init} message we encoded device names and states, but did not encode possible parameters (like temperature for AirCons or channel and volume for TVs). In the current version, parameters were added to the {\tt init} message, where the number of parameters is determined by the device types (e.g. light will always have one parameter - dim level).
\item In the original protocol, if an action is found to be illegal because it does not conform to the state of the house, an error message is thrown by the server without terminating the connection (i.e. action denial). Now all error messages cause the connection to be terminated, and the server    confirmation message is changed to have a parameter: 0 in case the action is denied and 1 in case it is applied.
\end{enumerate}

\subsection{DFA}
We applied 2 changes in the DFA:
\begin{enumerate}
\item Separated the first state (previously: ``IDLE, server listens to connections'') into 2 states, first is ``IDLE'' in which the client does nothing and the server listens to connections, and the second is ``Client awaits version'', where the client is waiting for a version message from the server.
\item Added explicit error messages in all states (red arrows) for any case an illegal message is received by either the server or the client. At such events, the error message is sent to the other side and the connection is terminated (and the states transitions back to ``IDLE'').
\end{enumerate}

In addition, since we eliminated the asynchronous behavior in the main communication phase (where now the client {\em must} receive a confirmation / denial from the server before he can invoke another action) and turned it into synchronous, no longer are the client action messages legal at the ``Client awaits confirm / deny'' state. If the client is at that state, it must wait for the client to send a confirmation / denial to go back to the ``Server awaits client action'' state. It follows that, at the ``Server awaits client action'' state, the server cannot send the client any confirmation / denial (since it cannot have a client pending action to process in that state).

\subsection{Extensibility}
We added elaboration on the version exchange phase, the heart of the extensibility characteristics of the RSHC protocol. In addition we added a reference to the PDU subsection that discusses the version exchange in detail, as suggested by the professor. The most prevalent addition to the extensibility section is examples on how the protocol can be extended in ways that add new states to the DFA (in the previous version we discussed only adding new messages, but not new states).

\subsection{Security Implications}
The security implications section in the previous version did not present the strengths of the RSHC protocol in terms of security well -- authentication and robustness against fuzzing. In this version we provided more details about the authentication scheme (specifically, how users are added to the system -- handled by the application, and not the protocol) and how the protocol and its messages are designed to provide good security against fuzz attacks. Moreover, we pointed out more clearly the fact that confidentiality and integrity can be trivially achieved by simply using SSL.
